This invention relates to computer programs for managing data entities or objects and, more particularly, to computer programs for managing data entities or objects that can, need, or should manage time-structured or other context data, with a seamless ability to persist to an industry standard relational database.
“Time structured” data is data that varies with time, e.g. stock prices or quotes, retail product prices, corporate titles, home addresses (past, current and future). With this type of data, the same attribute, e.g. the price, has a value that may be, and most likely is, different at different points in time. Computer programs that must manage data structures for time structured data are constructed idiosyncratically by individual programmers over and over on a case-by-case basis. Thus, despite the fact that most data is “time structured,” there is no uniform and consistent way of dealing with this type of data. In fact the complexity of managing this problem has generally been ignored.
Dealing with time structured information, e.g., stock quotes, has implications not only for program design, but also for the structure of databases for the information. One way to deal with information that changes over time is merely to store the current value of the variable, and overwrite it with new data when a change occurs. In this example, the user could ask for the price of the stock in ABC Company and the program would get the stock value of ABC Company from a data table of companies and stock prices in the database. However, this system would not be able to tell the user the price of the stock last month. To overcome this, the database would have to retain the stock price for at least a month in the past, and perhaps for the last twelve months. Thus, instead of a single table, there could be twelve tables of companies and stock prices, each for a separate month or other temporal period. Then the program would have to be directed to get the stock value of the company from the table containing the month in question. As the need to have stock prices over a longer period of time increase, the number of tables would increase. The same would be true if the information were needed more frequently than monthly, e.g., weekly, daily, hourly or by the minute or second. Thus, the database would get increasingly larger and more complex, and the program would also have to be more complex, e.g., to find the price at a particular second on the third day of the month, three months ago.
Further, with increased amounts of data, the program may be called upon to take more sophisticated action. Instead of giving the price at a particular time, it may be asked for the highs and lows for the year, or the trend, or to graph a five month running average of the stock price.
In this simple example, the storing of time data is simplified by having a separate data table for each period of time and storing the stock prices for each company of interest in a different table for each period of time. This creates a very large database, which could be reduced in size if only changes in stock prices and their time of occurrence was stored. This reduces the burden on the database, but complicates the program. In particular, it has to figure at what time a particular value of the variable was in effect.
In the prior art, either nothing was done about having an attribute whose value is “as of” a certain time or it was generally handled in independent unrelated fashion by individual programmers. In the case of a stock price quote database, the programmer creates a database model for storing the time structured data and then creates special routines for storing the time-structured data in the database as well as special routines for manipulating the time-structured data inside the memory of the computer program. This technique for handling temporal data in databases is described in Cummings et al., Temporal Databases, Benjamin Cummings Publishing (1983). In particular, in this text the authors disclose techniques in database programming for an “as of” parameter, but not with respect to programming objects.
Object-oriented programming is a form of modular programming that allows pieces of software to be reused and interchanged. In this form of programming self-sufficient modules that contain data and the processing or method (data structure and the functions that manipulate that data) are created, i.e., encapsulated. These user-defined data types are called classes. One instance or occurrence of a class is called an object. For example, in a payroll system, a class could be defined as a person, with information about the person stored as a data structure. Further, the capabilities of the person could be defined as functions which the person can perform. The stored information can be referred to as fields, member variables or attributes of the object or class.
The paper Suzuki et al., “Development and Performance Analysis of a Temporal Persistent Object Store POST/C++,” Doctoral Degree Program in Engineering, University of Tsukuba, Tennohdai, Tsukuba, Ibaraki 305 Japan suzu@dblab.is.tsukuba.ac.jp (Jan. 30, 1996) describes the use of Object Database Management Systems (ODBMS) in advanced database applications to manage complex objects and objects that have associated inherent procedures or methods. According to this paper, some applications require temporal and historical information management in the context of such object management. To accomplish this, a temporal persistent object model is proposed This model treats past states of persistent objects as different objects, and supports uniform manipulation of current and past states of objects. An implementation of a temporal persistent object management system, named POST/C++, is described. This system stores objects based on C++ and manages their histories of updates by user transactions based on the temporal persistent object model. Since each store is of a new object, the system is not very memory efficient. Further, while proposing a uniform way of dealing with (or manipulating) the temporal data, the paper does not propose a uniform way of dealing with (or manipulating) the temporal data stored while it is in use in an actual running computer program, especially one designed using an object-oriented language.
It would be advantageous if there were a unified way or common programming model for use by application developers in managing context date, e.g., time or temporal data information and point of view information.